loopkit: la carpeta .claude/ con 33 skills que promete que Claude Code deje de improvisar

Un post que ha corrido como la pólvora estos días en X y LinkedIn cuenta la historia de un ingeniero senior de Anthropic que, según él mismo, cobra en torno a 1,2 millones de dólares al año. Le preguntaron cómo consigue sacar el trabajo de un equipo entero él solo. En vez de dar una charla motivacional, colgó su carpeta .claude/ tal cual la tiene configurada. La cifra no se puede verificar y el post tiene todo el aire de un gancho para redes, pero la carpeta que enlaza es real, está en GitHub y cualquiera puede clonarla.

Se llama loopkit y la firma un usuario con el alias Archive228. Son 33 skills ya probadas más un harness mínimo para que un agente de código (Claude Code, Cursor, Codex o Gemini CLI) deje de improvisar cada vez que le pides algo.

La idea de fondo

La comparación entre Opus y Sonnet, o entre GPT-4 y GPT-5, ocupa media internet, como si el modelo fuera el techo. El argumento de loopkit va por otro lado: el modelo apenas cambia el resultado si detrás no hay instrucciones claras, permisos bien definidos y una forma de verificar lo que hace antes de darlo por bueno. Sin ese andamiaje, un agente adivina. Y cuando adivina, se inventa APIs que no existen, escribe tests que no comprueban nada o "arregla" un bug simplemente renombrándolo.

Qué instala exactamente

Con un único comando se despliega toda la estructura en el directorio del proyecto:

curl -fsSL https://raw.githubusercontent.com/Archive228/loopkit/main/install.sh | bash

El instalador no toca lo que ya tienes: si detecta ficheros existentes los deja en paz, salvo que fuerces la sobrescritura con FORCE=1:

curl -fsSL https://raw.githubusercontent.com/Archive228/loopkit/main/install.sh | FORCE=1 bash

Quien prefiera no ejecutar un script bajado de internet a ciegas (buena costumbre) puede clonar el repositorio y copiar las piezas a mano:

git clone https://github.com/Archive228/loopkit
cp -r loopkit/.claude loopkit/skills loopkit/.mcp.json loopkit/MEMORY.md loopkit/run.sh tu-proyecto/

Sea cual sea el método, esto es lo que aparece en el proyecto:

• .claude/CLAUDE.md: el contexto fijo del proyecto, unas 60 líneas con las reglas que el agente lee siempre.
• .claude/settings.json: qué comandos puede ejecutar sin preguntar y un hook que formatea el código nada más escribirlo.
• .claude/agents/verifier.md: un subagente que revisa el trabajo del primero antes de darlo por cerrado, con instrucciones para intentar tumbarlo.
• .claude/skills/: las 33 skills, cada una en su propio SKILL.md, cargadas solo cuando el contexto las necesita.
• .mcp.json: la conexión con servidores MCP externos.
• MEMORY.md: un índice de lo que ha pasado en sesiones anteriores.
• run.sh: el bucle que encadena planificar, actuar y verificar.

Las 33 skills, en nueve bloques

Cada skill es una técnica concreta, no un tutorial de treinta páginas: se lee, se adapta y se usa. Están agrupadas así:

• Agente/LLM: context-budget, spec-first, tool-restraint, subagent-fanout.
• Depuración: systematic-debugging, read-the-trace, bisect-regression.
• Seguridad: owasp-review, authz-check, input-validation, secret-scan, dependency-audit.
• Frontend: design-system, a11y-pass, loading-empty-error-states.
• Testing: write-failing-test-first, flaky-hunter, coverage-gaps, contract-test.
• Refactor: kill-dead-code, simplify, reduce-nesting.
• Documentación: changelog-from-diff, decision-record, readme-audit.
• Datos: sql-review, migration-writer, schema-diff.
• Git/Ops: clean-commits, pr-from-diff, rebase-safely, revert-surgical.

Hay un bloque más, de revisión, con una skill llamada adversarial-verify que recoge los once atajos típicos que toma un agente para fingir que ha terminado sin haberlo hecho.

Cómo usarlo en el día a día

La guía del propio repositorio propone un flujo sencillo una vez instalado:

1. Abre .claude/CLAUDE.md y ajústalo al proyecto real: convenciones de código, comandos de test, cosas que el agente no debe tocar sin permiso.
2. Revisa .claude/settings.json y decide qué comandos quieres autorizar de forma automática (build, test, lint) y cuáles deben pedir confirmación.
3. Cuando pidas una tarea, deja que el agente principal trabaje y que el subagente verifier revise el resultado antes de aceptarlo; no te fíes solo del "ya está".
4. Busca en skills/ la técnica que encaje con lo que vas a hacer (depurar, revisar seguridad, escribir el test antes que el código) y menciónala o deja que se active sola por el trigger de su SKILL.md.
5. Usa run.sh cuando quieras encadenar el ciclo completo de planificar, actuar y verificar sin ir dando el visto bueno paso a paso.
6. Deja que MEMORY.md se vaya llenando: es lo que le permite al agente no repetir los mismos errores de sesiones pasadas.

El propio autor lo resume con una frase que vale la pena quedarse: escribes la carpeta una vez y es la carpeta la que dirige al modelo en cada tarea siguiente, no al revés.

Todo el repositorio es MIT y está pensado para forkearse, así que nada obliga a usarlo tal cual: quien ya tenga su propio CLAUDE.md o sus propios hooks puede quedarse solo con las skills que le falten. Quien quiera indagar en la teoría detrás del harness (por qué esos siete ficheros y ese bucle de cinco pasos) tiene el enlace al artículo largo del autor dentro del propio README.

Para quien ya usa Claude Code a diario, en programacion.net puedes leer también cómo evitar que tus claves acaben en el contexto y qué trucos existen para ahorrar tokens sin perder productividad.

Imagen: Pexels / Markus Spiske.